Beyond MapReduce

儘管 MapReduce 在 2000 年以後很夯，但它畢竟是分散式系統中諸多程式框架中的其中一種，取決於數據量、數據結構和數據處理的類型，你還有其他更適合的工具可以使用。

MapReduce 是個很有用的學習工具，因為它是分散式系統上一個清楚和簡單的抽象，但是，易於理解不代表易於使用，用原生 MapReduce API 實現一個能動的 job 相當費力，就像你不會想從頭實現 join 算法一樣。

所以今天就來看看，除了 MapReduce 外還有哪些批次處理工具吧。

中介狀態的實體化 (Materialization of Intermediate State)

如同前幾天討論的那般，每一個 MapReduce 的 job 都是獨立的，有依賴關係之 job 的唯一接觸點是資料位置，第 2 個 job 的輸入是第 1 個 job 的輸出，所以有些工程師會仰賴外部工具來安排所有 MapReduce job 的調度。

然而在大多數的情況下，job 的輸出只會被另一個 job 來使用，所以分散式檔案系統上很多資料都處於 中介狀態 (intermediate state)，在一個使用 50 ~ 100 個 MapReduce job 的推薦引擎 workflow 下，其中介狀態資料的數量可以很驚人。

相比之下，Day 23 示範的用 Unix 工具分析 log 的例子就沒有這問題，管線命令 (pipe) 不會完整的實體化 (materialize) 中介狀態，而是以逐漸增量的方式，將輸出串流到輸入，而僅使用一個小的記憶體緩衝區。

跟 Unix 工具相比，MapReduce 這種完全實體化中介狀態的方法有以下缺點：

• 一個 MapReudce job 需要等前面的 job 執行完才會開始，如果發生 Day 25 講的 傾斜 (skew) 就會拖慢 job 處理速度。
• mapper 通常是多餘的，在某些案例下，你直接把 reducer 的輸出當做下一次 reudcer 的輸入會更快，省得用 mapper 再讀入一次，然後再做一次一樣的排序跟分區。
• 中介狀態的資料還是會被分散式檔案系統做副本到多個節點上，但其實不需要。

數據流引擎

感謝這些大神，我們有數個工具框架可以解決 MapReduce 的這些問題，像 Spark、Tez 和 Flink，儘管它們設計的方法不樣，但有一點是相同的：它們能將整個 workflow 視為單一個 job，而不是細分到多個 subjob。

因為它們將數據流拆成多個處理階段，所以也被稱為 數據流引擎 (dataflow engines)。

就像 MapReduce 那樣，它們會重複的呼叫 user-defined 函數來處理一條條的數據，也能在多個分區輸入中並行執行，並透過網路讓輸出成為下個函數的輸入。

不像 MapReduce 的是，這些函數並不會嚴格的把角色區分成 map 和 reduce，而是以更靈活的方式組裝，我們稱這些函數為 operator，數據流引擎提供多個選項連接這些 operator：

• 一個選項是做 重新分區 (repartition) 和以 key 做排序，就像 Day 24 的 MapReduce shuffle 一樣。
• 另一個選項是一次讀取多個輸入並以同樣的方法做分區，但跳過排序，這節省了做 Partitioned hash joins 的力氣，排序對 hash table 的建立沒有任何影響。
• 對於 Broadcast hash joins，來自同一個 operator 的輸出可以發送到 join operator 的所有分區。

你能使用數據流引擎建立跟 MapReudce 一樣的 workflow，而且執行的較快。